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Abstract 

Terminal area Air Traffic Management handles both 
arriving and departing traffic. To date, research work on 
terminal area operations has focused primarily on the 
arrival flow and typically departures are taken into 
account only in an approximate manner. However, 
arrivals and departures are highly coupled processes 
especially in the terminal airspace, with complex 
interactions and sharing of the same airport resources 
between arrivals and departures taking place in 
practically every important terminal area. Therefore, the 
addition of automation aids for departures, possibly in 
co-operation with existing arrival flow automation 
systems, could have a profound contribution in 
enhancing the overall efficiency of airport operations. 
This paper presents the conceptual system architecture 
for such an automation aid, the Departure Planner (DP). 
This architecture can be used as a core in the 
development of decision-aiding systems to assist air 
traffic controllers in improving the performance of 
departure operations and optimize runway time 
allocation among different operations at major congested 
airports. The design of such systems is expected to 
increase the overall efficiency of terminal area operations 
and yield benefits for all stakeholders involved in Air 
Traffic Management (ATM) operations, users as well as 
service providers. 
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1 Introduction 

Aviation researchers in the US (NASA, MIT) and Europe 
(e.g. DLR - German Aerospace Research Establishment) 
have recognized the need for enhanced airport surface 
traffic control systems. The Departure Planner (DP) 
project at MIT and the Taxi and Ramp Management and 
Control (TARMAC) system developed by DLR are both 
research efforts in this direction with the objective of: 

• Optimizing departing traffic, 

• Closing unnecessary gaps between arrivals and 
departures and 

• Establishing an integrated Ground Movement 
Planning System [10]. 

The development of (possibly automated) decision 
support tools for air traffic controllers calls for a 
thorough understanding of links and interactions in ATM 
operations and requires constant evaluation and 
assessment. Furthermore, the design of a high-level 
architecture for airport departure management should be 
based on a thorough analysis of the airport system and 
understanding of the needs and constraints in current 
airport operational procedures. To this end, a significant 
set of field observations has been done at Boston Logan 
International Airport [5], [6], [7] the results of which are 
summarized in Section 2. 

The observations and analyses discussed in previous 
work introduced significant issues that should be 
accounted for in the design phase of the Departure 
Planner [7]. Section 3 presents the suggested general 
architecture, which is expected to be sufficient for all 
aspects of departure management. The Departure 
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Planner is designed to include several components. Each 
of these components addresses a certain aspect of the 
departure process and its interaction with the arrival 
flow. The architecture proposed here, describes the 
control function of each component of the planning 
system, its inputs and outputs, as well as identifies the 
point along the departure flow where this function could 
potentially be introduced. In particular section 3.2 
highlights the Virtual Queue Manager (VQM) as the 
architectural component that is actually assigned with the 
task of Runway Operations Planning and coordination 
between arrivals and departures that use the same runway 
resources. Implementation issues are also addressed. 

2 The Departure Process - Results from 
Field Observations 

Analysis of departure and arrival operations at Logan 
(BOS) and other major US airports, such as Chicago 
O’Hare (ORD), Atlanta Hartsfield (ATL) and Dallas-Fort 
Worth (DFW) revealed significant operational delays and 
environmental impacts associated with the departure 
process [5]. Analysis also revealed that, while there are 
many similarities between the departure and arrival 
processes, there are also significant differences, which 
affect the way in which improvements may be effected. 
For example, beyond a certain entry fix point in the 
terminal airspace, the arrival stream is quite determined 
and there is not much opportunity for sequence 
adjustments. On the ground, however, there is little 
observability and high volatility associated with 
departure operations [6], [7] and controllers are presented 
with more opportunity to affect the final runway 
operations sequence. Therefore, since, in any case, 
safety reasons make controllers prefer to keep aircraft on 
the ground rather than in the air for flow management 
purposes, it will be potentially beneficial for ATM 
operations to design a decision-aiding system to assist 
controllers in handling and optimizing departure 
operations. 

Different components of the airport were identified as 
flow constraints, which introduce delays and 
inefficiencies and contribute to the low prediction 
capability associated with departures [5], [6], [7]. The 
flow constraints identified were associated with the main 
airport system elements: 

a) The gates complex 

b) The ramp area 

c) The taxiway system and 

d) The runway system 

The flow constraints manifest through the aircraft queues 


physically that form at the above elements. In that sense, 
an airport system can be modeled as a complex 
interactive queuing system in which departures and 
arrivals are highly coupled. Figures 1 and 2 illustrate all 
the different types of aircraft queues that form on the 
Logan airport surface in the configuration 22/27. 



Figure 1: Taxiway and Runway Queues at Logan 
Airport under configuration 22 / 27 

As shown in Figure 1, in this configuration, runway 27 is 
usually dedicated to arrivals, runway 22R is used only 
for departures and runway 22L is used primarily for 
arrivals. Often, pilots who specifically request a longer 
runway for takeoff, use the latter for departure, in which 
case they line up and wait on the south taxiway segment 
between 22L and 22R. When a large number of 
departures are expected, the airport switches to 
"Accelerated Departure Procedures" (ADP), in which 
case runway 22L is used only for departures and all 
arrivals are routed to runway 27 (see also Figure 6 in 
Section 3.1). 

The flow of arriving and departing aircraft through the 
airport system and the various queues forming on the 
airport surface in configuration 22 / 27 can be abstracted 
as in Figure 2. The physical elements of the airport 
system (gates, taxiways, runways) are depicted in the 
middle part of the figure and their interactions with the 
airport queues are shown as dashed arrow lines. Each 
bar between different queues represents a transition from 
one queue to another. Solid arrows represent the aircraft 
flow and dashed arrows associated with a specific airport 
resource, represent use of that resource for the queue 
transitions. Following the aircraft flow in Figure 2, an 
arriving aircraft queues on final approach and after 
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landing on runways 27 or 22L, it joins a runway-crossing 
queue waiting to cross runway 22R. After crossing, it 
joins other aircraft in taxiing queues, which include 
arriving and/or departing aircraft. Upon arrival at its 
assigned gate, it may have to wait for the gate to be 
released fi*om the previous aircraft. When the gate 
becomes available, the aircraft joins a pushback queue 
according to its scheduled departure time. Figure 2, 
depicts two different types of gates that were observed. 
In one case (far right side of Figure 2) aircraft that push 
back fi*om these gates enter the ramp area (e.g. Logan 
terminal A ramp in Figure 1) and wait in a ramp queue 
for ATC clearance to enter the departure taxi queue in 
the taxiway system. In the other case, aircraft push back 
directly onto the taxiway system with no intermediate 
ramp area (e.g. point X in Figure 1). At point Y, 
departing aircraft that are assigned runway 22R for 
takeoff enter the 22R takeoff queue. Departing aircraft 
assigned to take off on runway 22L, join the same 
taxiway segment but are considered to enter a runway- 
crossing queue in order to cross runway 22R before 
joining the 22L takeoff queue. 



Figure 2: Queuing Model for Logan Airport under 
configuration 22 / 27 

Figure 1 also shows the possible location of these queues 
on the surface of Logan Airport in the case of 
configuration 22 / 27. The two arrival queues on 
runways 27 and 22L are easily identified, as well as the 
departure queue that is formed on the taxiway segment 
adjacent to runway 22R. This departure queue includes 
aircraft that line up to take off from runway 22R and 
aircraft that will cross 22R to take off from 22L (ADP, 
Figure 6). Operations on runway 22R are impeded not 
only by aircraft departing on 22L but also by arriving 
aircraft that queue in taxiway segments between the two 
parallel runways to cross runway 22R. 

The above identification of the airport flow constraints 


and the associated queuing network was critical in 
studying the dynamics of departure operations. It 
enabled the definition of various control points where the 
departure operations could be affected by control actions 
and it also helped in determining the Departure Planner 
control options. 

The observed operations described above are tactically 
under the control of the air traffic controllers in the 
Control Tower. The air traffic controller has to clear 
each aircraft to use an airport resource such as a ramp, a 
taxiway or a runway, by delivering a “clearance 
instruction”. By observing the aircraft queuing process 
and the control process, it was possible to identify 
control functions, which occur at specific control points. 
The transitions in Figure 2 are examples of such control 
actions and control points. Most aircraft operations are 
under the control of the Tower and therefore, control 
actions and points are associated with the controllers’ 
clearances. However, some aircraft operations, such as 
engine-start, are not currently under the Tower’s control 
at Logan, 

The following control functions were identified based on 
the observations at Logan airport: 

a) Pushback clearance (for jets) or taxi clearance (for 
propeller-driven aircraft). 

b) Clearance to enter the taxiway system of the airport 
from the ramp area, gate where the aircraft is 
waiting. 

c) Runway and taxi-path allocation, i.e. the process of 
routing aircraft to a specific runway, through a 
predetermined taxiway path. 

d) Sequencing of aircraft takeoff, i.e. merging of 
aircraft into the same takeoff queue or mixing 
between aircraft from multiple queues (e.g. one jet 
aircraft and one turboprop aircraft queue) at the 
same takeoff runway. 

e) Takeoff release of each aircraft. If a runway is used 
by departures, landings and runway crossings, 
takeoff release also involves mixing of operations on 
that runway. 

It was observed that a control fimction could be exercised 
at different times and locations. For example, aircraft 
sequencing can be performed at the gate (pushback 
control), at the taxiway entry points as aircraft are 
released into the taxiway system and up to the physical 
point beyond which the aircraft have to commit to a 
particular takeoff queue. Once the aircraft are physically 
present at the runway end, the takeoff sequence is hard to 
modify. Therefore, notionally, a control point is defined 
as the last opportunity that the controllers have to apply a 
particular control fimction to the departure queues. A 
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control point can be a physical point on the airport 
surface, or it can be a point in time during the departure 
process, when the aircraft transitions from one state to 
another. For example, a control point exists at the gates 
when aircraft are cleared to push back into the ramp area. 
A possible control point is also the instant when aircraft, 
while taxiing, are handed off to a specific controller who 
handles a particular set of runways. At that point in time 
these aircraft are committed to enter a runway queue, 
with much less room for further adjustments than in the 
taxiing phase. The main control points associated with 
the observed operations outlined above are: 

a) The gate. 

b) The point of entry fi-om the gate or ramp into the 
airport taxiway system. 

c) The point of commitment to a specific queue 
(temporal or spatial) and 

d) The point of entry to an active runway (exit from a 
takeoff queue). 

The control points and the control functions are generic 
but there are airport specific and runway configuration 
specific differences. In [5] Atlanta Hartsfield (ATL) and 
Boston Logan (BOS) were compared. BOS has one 
runway system and minimal ramp area, while ATL has 
two runway systems and a well-defined ramp area. 
Therefore, BOS is usually operating with one departure 
queue. The structure of this queue can be primarily 
determined at the gate (pushback clearance control 
function), which in most cases is the point of entry into 
the taxiway system, since the intermediate ramp area in 
BOS is almost non-existent. On the other hand, ATL has 
at least two departure queues in most cases, as well as a 
larger controlled ramp area than BOS does. This means 
that the structure of the departure queues can be affected 
at the gate control point, but also to a larger extent at the 
taxiway entry points and through the mixing of aircraft 
from different queues. 

One of the main objectives of the Departure Planner is to 
mitigate the existing inefficiencies and reduce the 
observed delays resulting from the flow constraints that 
were described above. However, an airport system is a 
multi-objective environment with several stakeholders, 
such as airport users (airlines, passengers) and ATM 
service providers. Each of them attaches different 
“weights” to competing system objectives, which makes 
it hard to define a single objective fimction for the DP 
system. Some system objectives that have been 
identified are: 

a) Comply with safety and separation requirements, 

b) Maximize system throughput, 

c) Minimize taxi time (aircraft engine emissions), 

d) Consider noise regulations and constraints. 


e) Balance the load on all runways, 

f) Maintain the controllers’ workload at acceptable 
levels and, 

g) Provide fair treatment for all airport users 

In an effort to satisfy the above objectives, the Departure 
Planner is designed to include several components, based 
on the observed airport operations. These components 
are examined in detail in the following sections. 

3 Overview of the Proposed Departure 
Planner Architecture and Operational 
Context 

Field observations, as a method of airport system 
identification, helped in identifying the control points 
and functions mentioned above. The results from this 
analysis were combined with documented airport and Air 
Traffic Control (ATC) operations in order to generate the 
system architecture presented here. 

Figure 3 illustrates the two principal parts that the 
architecture consists of: 

Strategic Planner 

This is essentially a Configuration Planner that would 
typically have an approximately 3 to 4-hour time horizon 
and would perform configuration management tasks. 

Tactical Planner 

This part of the system has an approximately 15-30 
minute time horizon, performs tactical planning of 
runway operations under a specific runway configuration 
and exercises appropriate control to implement the 
generated plans. 

The most critical tactical component introduced in the 
system is the Virtual Queue Manager, The remaining 
three tactical system components (starting from the gates 
and following the departure flow to the runway takeoff 
queues) are: 

a) The Gate Manager, which is introduced in order to 
support the controllers in managing the pushback 
schedule given the unpredictability (uncertainty) 
inherent in airline gate operations and schedules. 

b) The Taxiway Entry Manager, which modulates the 
release of aircraft for entry into the taxiway system. 

c) The Mix Manager, which is introduced in order to 
manage the arrival/departure mix onto active 
runways. 

Detailed descriptions of the various DP components are 
provided in the following sections. 
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Figure 3: Overview of the Departure Planner system hierarchy 


In a generic framework that can be applied to any airport, 
each of the four tactical components is designed to 
exercise control and address inefficiencies at specific 
control points along the departure process. Each 
strategic and tactical component can be linked (mapped) 
to a group of objectives drawn from the family of the 
general functional objectives of the decision-aiding 
system that were presented earlier. At the same time, all 
components are envisioned to communicate and 
exchange data with each other directly or via a common 
Database Management System (Figure 3), The latter is 
designed to ensure that all components have access to the 
same consistent information. It should interact with 
several specialized databases containing necessary 
airport specific data, such as: 

• Airport topology 

• ATC procedures, regulations and restrictions, e.g. 
airport-specific arrival and departure routes, such as 
Standard Terminal Arrival Routes (STAR) and 
Standard Instrument Departures (SID) 

• Aircraft performance data, such as Eurocontrol’s 
Base of Aircraft Data (BADA), as well as 
dynamically generated data, such as: 

- Flight plans 

- Aircraft identification information 

• ATC constraints that are dynamically introduced, 
e.g. flight priorities, Groimd Delay Programs 


Generalizing, the main tasks of all components should be 
to: 

• Implement the designed virtual queue through 

control actions, taking into account: 

- Specific information and constraints for the area 
of operations that each component is associated 
with, i.e. gates, ramp, taxiways, runways and 

- Specific “settings” input in the system by the 
controller responsible for that area 

• Distribute information 

- To and between airport operators such as the 
controllers and airport users such as the airlines 
(external interface). An example of such 
external communication is the distribution of 
information to controllers that cannot be directly 
accessible by them, but is contained in other, in 
some cases remote, technical systems, such as 
central airline operations’ management systems, 
or local airline station control networks 

- In between system components (internal 
interface). Examples of such internal 
communication is the distribution of 
information about all performed control actions 
of a specific component, which are relevant to 
other components of the architecture, or the 
communication of new events that make certain 
system solutions infeasible. 
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In any busy airport, even with a fairly simple runway 
geometry, managing ground operations and planning the 
allocation of runway time to the various types of runway 
operations, can be a very challenging task. Any effort to 
design a decision-aiding tool deployed to assist air traffic 
controllers with this task must take into consideration 
several operational requirements, which arise primarily 
due to the presence of human operators in the process. 
For example, in managing airport ground operations, 
there are two main tasks to be performed: planning and 
control and both of them are inevitably performed in a 
distributed fashion, because of the many different parties 
involved in most planning and control functions. 
Therefore, a successful design of an automated decision- 
aiding system that will be under airport-wide use must 
take into account integration issues between the varying 
objectives, constraints, information requirements and 
control inputs from all stakeholders involved in airport 
ground operations, such as the airlines, airport 
authorities, airport service operators, passengers and the 
FAA personnel in the air traffic control tower and the 
TRACON room. As an example, consider the 
information needs of the gate personnel and station 
managers of a specific airline at an airport, as opposed to 
the information needs of the air traffic controllers in the 
tower cab. The latter have to deal with all incoming and 
outgoing airport ground traffic and not only the aircraft 
of a particular airline, which means that their information 
needs are apparently larger than those of the specific 
airline operators. In addition, the controllers’ objectives 
are naturally more system-oriented than the 
understandably profit-oriented objectives of an airline 
operations control center. 

It is uncertain how feasible it is for an automated system 
to take into account the objectives of all involved parties. 
Therefore, it is likely that the solutions suggested by such 
a system may not always be optimal. In addition, 
runway operations plans generated by the decision-aiding 
tool may even be unimplementable due to its inability to 
incorporate very dynamic last minute changes of the 
system state (e.g. traffic situation) that it was not aware 
of when those plans were calculated. Real-world 
applicability of the generated plans requires that the 
controllers have ample planning and control flexibility to 
modify the plans for factors and events not visible to the 
decision-aiding tool and that the solutions generated are 
presented to controllers as operational guidelines and not 
as inviolable laws that they have to abide to. 

On a final note, careful consideration must be given to 
’’usability” and the interaction between the controller and 
the decision-aiding tool in the context of the operational 
environment and standard procedures within the ATC 


tower. The underlying structure of the decision aid and 
optimization process must be clear to the controller and 
the results must be consistent with the controllers’ 
heiuistic estimates. In addition, the interface limits 
’’head-down" time for controllers. It should also be noted 
that the tool could be used as a communication device 
between controllers. Controller interface devices, which 
support these functions in the tower cab environment, are 
under development. 

3.1 Configuration Planner 

The Configuration Planner attempts to match the 
airport’s operational capacity as closely as possible to the 
scheduled demand, always taking under consideration 
limitations imposed by the forecasted terminal weather 
and by environmental constraints (aircraft engine noise 
and emissions), such as noise restrictions. 

Functionality 

The main task performed by the Configuration Planner is 
the development of the runway configuration plan for the 
airport so that all arrivals and departures expected to 
utilize the airport runway resources can be handled. It 
must be designed to take into account the stochasticity 
associated with weather. Accurate terminal weather and 
wind forecasts in conjunction with the pertinent noise 
abatement rules are used to define the set of feasible 
configurations for the airport. Based on these, the 
Configuration Planner determines the number of hourly 
operations that the airport can handle and the expected 
arrival and departure demand over successive intervals 
during the planning horizon is then matched to each of 
these configurations (level 1 in Figure 4), in order to 
design the best configuration strategy throughout the day. 


Operational constraints 



Figure 4: The Configuration Planner 
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In order to accommodate short-term demand fluctuations 
(Figure 6) the Configuration Planner should be able to 
suggest discrete operating modes within the time horizon 
of each of the planned configurations (level 2 in Figure 
4), especially since the response time of the airport to a 
change from one operating mode to another within the 
same runway configuration is quicker than the airport 
response time in the case of a full change of runway 
configuration. 

Supporting Analysis 

Figure 5 presents examples of four capacity envelopes 
that were generated based on airport throughput data 
over the course of 15 days. The data was collected from 
the air traffic control tower records as well as ETMS 
records from the FAA’s CODAS database [8]. 
Evidently, different runway configurations at Logan 
airport yield different capacities. In their effort to match 
the levels of demand expected, the controllers try to use 
the configurations with the highest arrival and departure 
capacity. However, the final selection is dependent on 
the weather and wind conditions at the airport. In 
addition, there are several noise abatement rules that 
limit the use of certain runways at certain times of the 
day. These weather and noise constraints are taken into 
account by the controllers in their decision-making 
process for selecting the airport runway configuration. In 
fact, at Logan airport, there are certain runway 
configurations that are recommended at night hours. 



Actual Departure Rate (per 1 5 minutes) , 

Figure 5: Runway Configuration Capacity Envelopes 
(Source: ETMS / Tower Records, 7-9 AM, 4-8 PM, 
July 1-15 1998 except Saturdays, Logan Airport) 

Matching different possible configurations to the 
schedule takes into account the time required for 
transitioning between configurations, which can take 
values up to 20 min for a busy period at major airports 
like Logan. When the arrival flow is very high, it takes 
longer to implement a configuration change, because it is 


harder to interrupt the arrival stream on final approach. 
For example, at Logan airport, switching to a high 
capacity configuration is usually attempted before 
periods of expected high traffic. 

Short-term fluctuations in the arrival/departure mix drive 
the airport in “departure push” or “arrival pull” mode. In 
these cases, the air traffic controllers perform short-term 
configuration changes by adjusting the operations that 
are assigned to utilize each runway within the current 
configuration. These configuration changes correspond 
to transitions between different operating points on the 
airport’s capacity curve [7]. For example, in normal 
operations within the 22 / 27 configuration, runway 22L 
is used both for arrivals and departures. However, when 
Logan airport is in a departure push mode, runway 22L is 
sometimes used only for departures (together with 22R) 
and all arrivals are assigned to runway 27. Figure 6 
shows the effect on the departure / arrival mix, by 
superimposing periods when ADP was used, over the 
capacity envelops presented in Figure 5 [8]. 



Figure 6: Accelerated Departure Procedure (ADP) 
(source: ETMS, July 1-15 1998, Logan Airport) 

In matching the scheduled demand to the set of possible 
configurations, the configuration planner should take into 
account the uncertainty inherent in departure operations. 
Departure demand is affected by airline decisions on 
delays and cancellations, which are not always known 
sufficiently in advance. Collaborative Decision-Making 
(CDM) is a step towards addressing this problem. It has 
been shown that advance cancellation notices have 
improved noticeably after the introduction of CDM [1]. 

3.2 The Virtual Queue Manager 

The Virtual Queue Manager (VQM) proactively manages 
the airport’s Virtual Queue so that DP objectives are met 
and therefore airport resources (runways, taxiways and 
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gates) are efficiently utilized. 

Virtual Queue Definition 

A Virtual Queue can be defined as a notional waiting line 
of departing aircraft arranged, at any instant of time, 
according to the order in which they are expected to take 
off. It consists of: 

a) A “physical” part, which involves aircraft that are or 
will shortly be physically present at a certain 
location on the airport surface, with no further 
chance for re-sequencing; therefore, these aircraft 
have a fixed (“frozen”) position in the virtual queue. 

b) A “virtual” part, which involves aircraft that are 
scheduled to occupy a particular position in the 
sequence of aircraft that will take off, but are not 
physically present in the takeoff queue yet. Position 
assignments in this virtual part of the virtual queue 
are very much subject to revision. 

In other words, the Virtual Queue can be seen as an 
extension of the notion of a physical queue that depicts 
the final takeoff sequence of all scheduled departures as 
the Departure Planner has planned it up to the current 
point in time. 


minutes before their assigned takeoff time and 
b) The “virtual” part, in which the scheduled departure 
time and the sequencing of some aircraft may be 
subject to change due to the fact that there is still 
considerable time to go, e.g., more than 15 minutes 
until the actual departure event 

The mode of interaction between the Virtual Queue 
Manager (VQM) and the other DP tools is still a research 
issue. One possibility is a "Master-Slave" relationship, 
in which the optimization logic is entirely included in the 
Virtual Queue Manager. Each of the DP components 
simply relays information and communicates its specific 
requests to the VQM with the hope that the system status 
will allow its requests to be satisfied. Another possible 
design philosophy is for each of the DP components to 
carry its own optimization logic and perform a local 
optimization dealing with a specific subproblem of the 
overall problem. Subsequently, the Virtual Queue 
Manager takes all the individual optimization results 
from Ae DP components and attempts to combine all the 
“local” solutions into a “global” one. This process may 
involve iterations and re-optimization until a feasible 
solution is achieved. 


If two or more departure runways are currently in use, or 
are expected to be shortly, then multiple virtual queues 
(one for each departure runway) will be in use. As an 
alternative, in such cases there might be a single virtual 
queue with each aircraft in the queue being “tagged” to 
indicate which departure runway it will use. 

Functionality 

In Figure 3, the VQM is hypothesized to reside in the 
system hierarchy at one level above the tactical DP 
elements. It interacts separately with the strategic 
configuration planner and also acting as a central 
processing function it coordinates the three tactical DP 
components. It incorporates all the requests from various 
physical queues in the system and relays back to them 
information about generated runway operation plans, the 
virtual queue and the required control actions in order to 
implement it. The major challenge is to design the 
optimum size of the virtual queue (minimum buffer size) 
in such a way that the aircraft queues in the system 
(especially the runway takeoff queue) are not 
consistently “starved” or saturated. 


Without 
Virtual Queue 


With 

Virtual Queue 


Runway ^ 
queue 


Taxiing* 


Pushback 
to taxi ^ 


Called “ready to 
push back” • 

Planned 
(anticipated ♦ 
to call) 



Since the runway was observed to be the main flow 
constraint, a possible design of the virtual queue is 
generated assuming that its “physical” part resides at the 
runway threshold. In this case, the two parts of the 
virtual queue would be: 

a) The “physical” part, including flights whose position 
in the queue may be “frozen” a few (10 or 15) 


Figure 7: Managing the departure sequence of the 
same 20 scheduled flights, with and without the 
implementation of a Virtual Queue (right hand side 
indicates the current optimal sequence) 

Figure 7 provides a hypothetical means to visualize the 
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virtual queue and understand its potential benefits. Each 
side of the figure represents a snapshot of the takeoff 
sequence as it is currently projected in the future. The 
“left hand” side represents the observed behavior where 
aircraft are transitioned from one state to the next mainly 
in a First Come First Serve order and where the queue 
buffer sizes are not controlled resulting in unnecessarily 
overloaded takeoff queues and taxiway congestion. The 
“right hand” side in Figure 7 represents the behavior with 
the implementation of the Virtual Queue, which provides 
a tool for effectively controlling the number of aircraft in 
each state at each point in time and regulating the timing 
of aircraft transitions from one state to the next. Aircraft 
move from the gate to the ramp onto the taxiway system 
and into one of the takeoff queues, following the timing 
and sequence schedule commanded by the Virtual Queue 
Manager. This optimal (or near-optimal) sequence is 
determined based on the system-wide objectives and 
constraints that were discussed earlier. 

Each line corresponds to a departing flight scheduled to 
take off within the time span that the virtual queue 
covers. In each case, the state of the departing aircraft is 
represented by a specific symbol as follows: 

a) Physically present at the runway threshold 

b) Taxiing 

c) Pushed back from the gate but not yet released into 
the taxiway system (ramp area) 

d) Waiting for pushback clearance from the tower, after 
having called "ready for pushback" and 

e) Expected to call "ready for pushback" within a pre- 
determined time horizon. 

Due to high workload, it is very hard in most cases for air 
traffic controllers to mentally determine the appropriate 
timing and sequence of departures, while at the same 
time keeping in mind all constraints and satisfying all 
system objectives. The existence of the virtual queue 
may assist controllers to determine possible "aircraft 
takeoff swaps" within the same state or even between 
different aircraft states (arrows in Figure 7) in order to 
optimize departure operations. The virtual queue may 
point out some of the optimal sequences that the 
controllers may not realize under heavy workload (see 
examples in Figure 8 and Figure 9). In addition, the 
virtual queue may be used to convert taxi delays to gate 
delays, which are less costly both for the airlines and the 
environment. In addition, operational flexibility for the 
airlines can be increased without sacrificing fairness. 

The VQM can be designed to exercise two levels of 
control on the allocation of runway time to different 
operations: 


• Simple control of the size and/or sequence of takeoff 
queues and 

• Time-based control. 

In the second case it is expected that the solution quality 
will be enhanced, but at the same time the computational 
complexity of the problem may be increased. 

Supporting Analysis 

The following analytical examples are extracted from 
observations of real-world operations at Logan airport. 
They are used to describe actual inefficiencies in runway 
utilization due to ATM operational constraints and also 
demonstrate the potential benefits that the airport system 
can have from efficient utilization and sequencing of the 
runway resources. Figures 8 and 9 present actual 
operations at Logan airport on February 2, 1999 under 
configuration 22 / 27. Figure 8 displays the progress of 
five departing flights through time. From left to right, 
the following time events are given: 

a) Scheduled departure time 

b) Time the pilot called “ready” to leave the gate 

c) Time the clearance to pushback (for jets) or taxi (for 
props) was granted by the tower 

d) The “Monitor Tower” time which (in this 
configuration) is the time that each departing aircraft 
is cleared to join the takeoff queue. This is the point 
where controllers usually exercise sequencing 
control among departures. 


Scheduled “Call Pushback/Taxi Monitor 

Dep. Time Ready” Clearance Tower Rwy 22R Rwy 22R 



Figure 8: Miles In Trail (MIT) restrictions 


The two remaining timelines in each of Figures 8 and 9 
describes the takeoff and crossing operations on runway 
22R (presented once in scale and once magnified). Each 
departure and crossing event has a record of the time the 
aircraft was cleared to take off or cross runway 22R. 

In Figure 8 Chicago-bound flights (ORD) were under a 
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20 Miles-In- Trail (MIT) restriction. Hypothetically, 
departure 1, which called ready to push back at 6:41 am 
after departure 5 (6:40 am) was sequenced to take off 
before the latter, so that ORD-boimd departure 5 
maintains a 20 MIT separation from prior ORD-bound 
departure 3. Departures 2 and 4, which called ready for 
pushback before or together with departure 5, ended up 
behind the latter in the takeoff sequence. Flights 2 and 4 
could have been sequenced to take off before flight 5, 
which was already delayed due to the MIT restriction, 
resulting in more efficient runway throughput. Note that 
in a 5-minute period between flights 1 and 5, the runway 
was used only for two aircraft crossings (asterisk ♦ 
symbols on the runway 22R timeline). The data 
collected showed that there were: 

• A “runway idle” time gap of 104 sec, between 
departure 1 and the first crossing event that occurred 
immediately after it (6:49 to 6:50:44) 

• A gap of 106 sec (6:50:44 to 6:52:30) between the 
two crossings and 

• A gap of 90 sec (6:52:30 to 6:54) between the 
second crossing and the next departure 5. 

Looking at the utilization of runway 22R, it is suggested 
that there is room for assisting air traffic controllers in 
designing takeoff sequences under several operational 
constraints, with an objective to avoid such unnecessarily 
large utilization “gaps” and achieve higher takeoff 

throughput. 

/ 

Similarly, in Figure 9, we can observe large time gaps 
between successive takeoffs with only one crossing 
operated within each gap. For simplicity, the “call 
ready” timeline has been omitted. The five departures 
examined here call ready and pushback in the order 1, 3 
& 4, 2, and 5. Departure 5 called ready for pushback 
(9:18) after departure 2 (9:09). However, it was 
sequenced to take off before the latter, probably due to 
the fact that, in this configuration, the estimated taxi out 
time for flight 5 is lower than the one for flight 2, based 
on the distance from each flight’s originating terminal to 
the runway 22R takeoff point. From this example, it is 
obvious that controllers actually implement certain 
sequencing rules, based primarily on their vast 
operational experience. Nevertheless, there seems to be 
room for improved sequences, in order to avoid 
excessive “runway idle” time. Focusing on the takeoff / 
crossing timeline in Figure 9, we can see that in each of 
the four time intervals between the five departures, there 
was only one crossing operated. Each crossing occurred 
very soon after the preceding takeoff and for the 
remaining time until the next takeoff, the runway 
remained idle. Based, on the wake vortex separation 
requirements for the aircraft types present, only the gap 
between departures 1 and 4 needed to be as long as it 
actually was. 


Scheduled Pushback/Taxi Monitor 

Dep. Time Geaiance Tower Rwy22R Rwy22R 



Note that, even if a takeoff sequence is very well 
designed based on the latest information available to the 
controllers, there are always unexpected events that can 
cause serious deviations from the planned takeoff order. 
For example, departure 2 may have been carefully 
sequenced after departure 5, as mentioned above. 
However, it was cleared to take off 140 sec (9:30:40 to 
9:33:00) after the previous crossing aircraft cleared the 
runway and 4 min (9:29 to 9:33) after the previous 
takeoff occurred on the same runway. This could have 
possibly happened because the takeoff weight and 
balance calculations were not available for departure 2, 
even though it was first in the takeoff queue. In other 
cases, scheduled or non-scheduled priority flights (e.g. 
lifeguard flights) or aircraft in the departure queue unable 
to takeoff can perturb the takeoff sequence. 

3.3 The Gate Manager 

The Gate Manager is the DP component that assists the 
controllers in determining the pushback schedule, subject 
to the uncertainty associated with airline gate operations. 
Initial runway assignments for departing flights may also 
be an important part of the Gate Manager’s task. 

Functionality 

Being the first DP component that can have an effect 
along the departure flow, the Gate Manager incorporates 
and processes data generated from the rest of the DP 
system components, as depicted in the “free body 
diagram”, shown in Figure 10. 

Note that, arrows pointing inwards toward the Gate 
Manager carry information (flight status data, system 
constraints) coming from other elements, which are 
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adjacent to the Gate Manager in the system architecture, 
or from other National Airspace databases that exchange 
data with the Departure Planner (e.g. Surface Movement 
Advisor (SMA), Center TRACON Automation System 
(CTAS)). On the other hand, arrows pointing outwards 
from the DP component convey to the rest of the system 
commands and requests generated by the Gate Manager 
function. A similar convention is used to read the “free 
body diagrams” presented for the remaining system 
components that are described in the following sections 
(Figures 13 and 15). 
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Figure 10: The Gate Manager 


Initially, based on traffic information from the gates, the 
ramp area and the taxiway system (Figure 10, top left and 
right data blocks), the Gate Manager assesses the current 
airport situation and suggests a feasible pushback 
schedule within a pre-determined planning horizon. At 
this point, data necessary for an accurate estimate of the 
current and projected demand (possibly obtained from 
the SMA database) are airline specific data, such as 
hangar status, current towing operations, and flight 
specific data local to each gate, such as destination, 
“tum-around readiness" messages, and taxi-out time 
estimates (Figure 10, middle left and bottom data 
blocks). In addition, downstream constraints such as 
gate holds and Ground Delay Programs (Figure 10, top 
right data block), which usually involve many 
cancellations, delays and gate rescheduling must be 
communicated to the Gate Manager as soon as the related 
information is available from the FAA central flow 
control (System Command Center). 

Many of the airline operations, especially the ones 
performed before aircraft are actually ready to push back 
from their gates, are not observable by the controllers. 
For example, oftentimes aircraft will call ready for 
pushback before their gate operations are actually 
complete, anticipating a delay between the call for 


pushback and the actual time that a clearance is granted. 
Sometimes, delays and cancellations due to inclement 
weather or mechanical problems, result in aircraft being 
held at their gates and cause unexpected gate blockages. 
With DP, such situations can be observed by controllers 
through the exchange of pertinent information between 
the Gate Manager and the Database Management 
System. 


Supporting Analysis 

One control strategy is to limit the number of aircraft 
released in the system by holding some of them at their 
gates. This method is fairly easy to implement, however, 
it may raise gate capacity issues, since it transfers 
runway queue delays to gate delays [7]. Controlling the 
gate release times with the help of the Gate Manager 
provides the controllers with a unique opportunity to 
implement the above control strategy, to control the size 
of takeoff queues and the sequencing of aircraft within 
the queues. 


In view of this control option, Airline Service Quality 
Performance (ASQP) data was studied in [9] and a 
simple dynamic queuing model for departure operations 
was developed and used to analyze airport surface 
operations. Based on the analysis results, simple 
departure control strategies were suggested for the 
purpose of alleviating surface congestion. As presented 
in [9], an important parameter in the problem of 
departure control appears to be the number N of aircraft 
that are present in the system while an aircraft is taxiing 
out from its gate to the assigned departure runway. It 
was realized that, as the number N increases, the 
expected value and variance of the taxi out time also 
increases, as shown in Figure 11 for one year of data 
from Boston’s Logan airport. 



No. ofAircran Taxing ()u( 


Figure 11: Taxi out time as a function of airport 
congestion (BOS: 1997/09-1998/08) 


In addition, for each airport and under any configuration, 
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there is a runway saturation point beyond which there is 
no significant gain in takeoff rate even if controllers keep 
releasing more aircraft in the system, as shown in Figure 
12. It is observed that, as controllers release more 
aircraft in the system, less than the released number of 
aircraft actually takes off and the remaining form 
congestion queues on the airport surface (Figures 1 1 and 
12 from [2]). 


1 

i - 

- -4 ' - 
1 

- f- : 

5 0.35 j “ • - 

-i - ■ - ■ 

f 

t i“ -i 

1 ' T 

“■ 

i - - ■ 

i 

. ... . 

. .. . j i 

^0.2S\ ^ ^ 

4. 

. ,_4 .. .. 

-i- - ^ 

' ■■ 

1 ■■■ - ■ 

.. ..p.. . . 


t2' ^ 

0.15 |- - ; ■ 

i 

1 

— i 

- |- • - ' 

0.1 f - - ■■■[ ■■ 

..} .. ... 

- -1 - - 

I i 

0.05 • ■ 

J — . 

1 


0 -t- — *■ 

0 5 

10 

15 

20 25 30 


No. of Aircraft Taxiing Oit 


Figure 12: Takeoff Rate saturation point (BOS: 
1997/09 - 1998/08) 

Based on downstream requests the schedule can be 
adjusted through gate release control to feed the takeoff 
buffers with the requested number of aircraft. The 
system-wide objective of maximizing airport throughput 
is addressed and pre-allocated departure slots can be met. 
Engine-running times are also minimized and 
compliance with environmental emissions regulations is 
achieved, while gate-blocking delays are significantly 
reduced. Furthermore, the airlines benefit fi*om fuel 
savings and late passenger / baggage accommodation by 
remaining at the gate until they can actually be accepted 
in the taxiway system, as opposed to pushing back on 
time and being delayed in holding pad areas or in 
taxiway queues. 

3.4 The Taxiway Entry Manager 

The Taxiway Entry Manager determines the sequence 
and timing of release from the ramp into the taxiway 
system for aircraft that have pushed back from their gates 
and entered the ‘Yamp buffer” in Figure 3. It considers 
system objectives related to the total time that each 
aircraft spends on the ramp or taxiing with its engines 
running. 

Functionality 

The Taxiway Entry Manager can affect departure 
operations by regulating the flow of aircraft through the 
interface between the gates and the taxiway system, 


which was identified as another possible control point in 
the departure flow [6], [7]. The Taxiway Entry Manager 
provides a means of indirectly controlling the runway 
takeoff queues, by controlling the total number of 
departing aircraft that will be distributed to them. Note 
that, depending on the specific airport geometry and 
complexity, this interface can take various forms. At 
Logan, there is a set of entry points to the taxiway system 
with little or no ramp area around the various terminals, 
while other airports, such as Atlanta Hartsfield or 
Chicago O’Hare, have a ramp area of considerable size 
adjacent to the terminals. 
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Figure 13: The Taxiway Entry Manager 


The current and projected taxiway situation (congestion 
levels) feeding back from simple observations or from 
sophisticated airport surveillance systems (in the future) 
and the takeoff queue (buffer) size feeding back from the 
Mix Manager are the most critical pieces of information 
for the Taxiway Entry Manager (Figure 13, top right data 
block). Accurate short-term estimation of pushback 
operations and prediction of the demand to enter the 
taxiway system must also be performed and the results 
fed into the Entry Manager, in order to avoid overloading 
the entry points (Figure 13, bottom left data block). All 
the above information is processed under the constraints 
of environmental regulations on aircraft engine emissions 
(Figure 13, top input). The outcome of this system 
element (Figure 13, bottom right data block) could be a 
feasible schedule of release times for aircraft to enter the 
taxiway system, which also meets the system objective of 
minimizing aircraft taxi times and therefore engine- 
running times, emissions and airline direct operating 
costs. 

“Engine-start” time control is an additional issue 
pertaining to the environmental impact from aircraft 
engine noise and emissions, which deserves further 
examination. In current operations, only pushback and 
taxiway entry clearances are commanded by terminal 
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ATC and the exact time that aircraft engines are started is 
left entirely to the pilot’s discretion. The Gate and Entry 
Managers could possibly schedule the movement of 
aircraft under the additional objective of postponing 
engine start times until as close to the taxiway entry 
clearances as possible. This is an example of the kind of 
coordination between two tactical subcomponents, the 
Gate Manager and the Taxiway Entry Manager. At 
Logan, where ramp space is limited, the two 
subcomponents can be merged into a single tool. 


3.5 The Mix Manager 

The Mix Manager regulates the release of departing 
aircraft fi*om each “runway buffer” onto the 
corresponding runway (runway A or B in Figure 3) as 
well as controls the release of aircraft fi-om the runway 
crossing queues building up on the taxiway segments. 
The coordination of operations on dependent runways 
and the mixing of arrivals, departures and crossing 
operations on a single runway are its main tasks. 


Taxi path modifications - Runway reassignments 
It should be noted that departing flights push back from 
their gate with an initial runway assignment, which they 
usually maintain until takeoff. Nevertheless, initial 
runway assignments and taxi paths are not always 
constant. When for example, a taxiway segment is 
unexpectedly blocked or there is a short-term or 
scheduled runway configuration change or the load in a 
certain takeoff queue is high, a runway reassignment may 
then be needed. Had the controllers had prior knowledge 
of the particular circumstances that led to the need for a 
runway reassignment, their pushback and taxiway entry 
clearance deliveries could have been different and also 
additional workload imposed on them and additional cost 
and delays imposed on the airlines could have been 
prevented. In the context of the Departure Planner, 
reassignment and rerouting may also be necessary in 
order to implement the Virtual Queue planned sequence, 
which is very dynamic. 


Functionality 

Air traffic controllers usually prefer to assign arrivals and 
departures to different runways. However, this is not 
always feasible, especially in tightly constrained airports 
such as Boston Logan. For many configurations, the 
runway resource utilized by departing aircraft is shared 
with arriving aircraft, which in most cases have priority 
over departures. In addition, the runway system is 
frequently shared with taxiing aircraft that have to cross 
active runways. As illustrated in Figure 14, the 
controllers often have to introduce gaps in the arrival 
stream in an effort to accommodate departures between 
arrivals and to allow taxiing aircraft to cross active 
runways. Sharing of the runway resources introduces a 
strong coupling between the arrival and the departure 
streams [5], [6], [7]. This suggests that we must consider 
and manage airport runway resources as sets of 
dependent runways, as opposed to individual runways. 


Potentially, an additional subcomponent could be 
inserted at this point in the system architecture to assist 
controllers with their runway reassignment and taxi 
routing decisions and to help them implement the Virtual 
Queue. Such a component is not currently included in 
the proposed DP architecture because it is believed that 
the taxi ground operations are not amenable to 
automation and are better handled by the experienced air 
traffic controllers. In the current operational 
environment, operations at the gates / ramp and at the 
runway, are supported by automation systems, such as 
CTAS and SMA, which are already in place and can be 
interfaced to the proposed DP components. On the 
contrary, automation during taxiing is hindered by the 
lack of surveillance information. In fact, in managing 
taxi operations, air traffic controllers obtain (visually) 
downstream information regarding the size and sequence 
of each takeoff queue, as well as the current status of 
each of the available runway queues. Such information 
can possibly come from downstream DP components 
such as the Mix Manager (see next section 3.5). 



Figure 14: Runway Operations Schedule: Mixing of 
Arrivals, Departure and Runway Crossings 


Figure 15 describes the interaction of the Mix Manager 
with the rest of the aircraft flow at an airport system. As 
suggested it is the connective component between 
terminal airspace traffic (departures ascending within the 
terminal airspace and arrival flow approaching the 
airport) and airport surface traffic (the set of departing or 
arriving aircraft that are physically present on the 
taxi way system). 

As shown in Figure 15, working under a given runway 
configuration and a specific mode of operations (Figure 
15, top data block), the Mix Manager processes the 
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following inputs: 

• Projected takeoff demand information, based on 
inputs from the actual and projected pushback 
schedule (Figure 15, bottom left data block). 

• Projected landing demand information from the final 
approach arrival queues that are forming in the 
terminal area (Figure 15, top right data block). 

• Data on downstream constraints, such as miles in 
trail and departure fix capacity (Figure 15, top right 
data block). 

Collaborative Decision-Making (CDM) can play a vital 
role at this point, in providing accurately updated 
demand information (cancellations and delays) to the air 
traffic controllers and to the mixing function of the Mix 
Manager. 



Figure 15: The Mix Manager 


The main output generated from the Mix Manager is the 
suggested schedule of aircraft release from the takeoff 
and runway crossing queues (Figure 15). Requests for 
gaps in the arrival flow could be given to the TRACON 
controllers, in order to implement the suggested takeoff 
releases. In addition, specific tactical suggestions on the 
sequence and size of takeoff queues can be 
communicated to the tower controllers as a basis for 
carrying out efficiently the gate pushback and taxiway 
entry processes. 

Supporting Analysis 

In Logan configuration 22R-22L-27, which was 
presented in Figure I, arrivals using runways 27 and 22L 
have to cross runway 22R to reach the terminal area. 
Crossing aircraft queue in the taxiway segments between 
runways 22R and 22L but when there is no more space 
for queuing aircraft, the departure stream on 22R has to 
be interrupted for crossings to occur and for making 
runways 22R and 27 available for further landings. 

Figure 16 clearly demonstrates how takeoff operations on 


runway 22R are affected by the presence of crossing 
aircraft. When one or more crossings were operated 
between successive takeoffs on 22R, the mean time 
between the two takeoff clearances for the data sample 
presented is 1 min and 59 seconds. The mean value 
drops to only 45 sec when successive operations occur 
with no crossings interjected between them. The overall 
mean time for the whole data set is 1 min and 10 sec. 



Inter Takeoff Clearance Tin^e (min:sec) 


Figure 16: Runway Crossing Effect on Inter-Takeoff 
Clearance Time (Source: Local Controller 
Clearances, Runway 22R, Logan Airport, 12-2-1998, 
4-9PM) 

The Departure Plaimer caimot be developed 
independently from CTAS or other arrival automation 
tools, which carry information critical to DP for 
successful configuration planning and arrival/departure 
mixing. In fact, the arrival-departure interaction 
introduces a new complex challenge for existing tools, 
such as CTAS, which will now have to be enhanced to 
take departures into account. DP can have important 
inputs to CTAS and especially Active FAST (Final 
Approach Spacing Tool), such as the runway crossing 
and takeoff queue information. These inputs can then be 
used to determine the most appropriate sequencing and 
tactical spacing of arrivals (introducing the necessary 
gaps in the arrival stream. Figure 14). 

4 Conclusions 

The Departure Planner, as presented in this paper, is 
intended to assist short-term planning operations at major 
commercial airports. Its emphasis will be on supporting 
Air Traffic Management in the next 30 to 45 minutes 
from the current time, but it also has a component that 
does planning with a time-horizon of a few hours. It 
consists of a set of fimctional components; some used for 
strategic ATM operations such as configuration planning 
and some for tactical departure planning. DP is not 
necessarily viewed as a fully automated system. These 
components could potentially become automation tools 
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used by the controllers to manage the various physical 
queues existing in the flow of departing aircraft, without 
increasing workload levels, 
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